1. Field of the Invention
The present invention generally relates to a computer-based service directory and, more specifically, to a method and system for discovering a service element on a network which can handle continuously updated service records.
2. Description of the Related Art
Service discovery has been a popular subject of interest in computer science in recent years. It started with a simple idea of finding a device, for example, a printer that is nearest to a conference room, and this concept has since expanded to finding web services on the Internet. A Universal Description, Discovery and Integration (UDDI) project provides a framework for describing services, discovering businesses, and integrating business services on the Internet by using a web-based distributed directory. Web Services Description Language (WSDL) is an XML-formatted language used to describe service capabilities as collections of communication endpoints capable of exchanging messages. A directory is generally used to hold service records about the services that are available for a client to use. It normally resides at a well-known network address. The clients, service directories, and service providers may be widely distributed on the network. A service provider is loosely defined to be any software program that provides some form of programming response to a programming request.
A Domain Name Service, or DNS (P. Mockapetris, “Domain Names—Implementation and Specification,” IETF Network Working Group Request for Comments 1035, November 1987), is widely used by network programs to find the IP address of a host on an IP network. During the early days of the Internet, static IP addresses were mostly used. A simple view of the DNS is a list of host names and their associated static IP addresses. This list changes as often as hosts are added or removed from the network, which is not too often. When the network administrator starts to run out of static IP addresses, dynamic IP address allocation may be used, in accordance with the Dynamic Host Configuration Protocol, or DHCP (R. Droms, “Dynamic Host Configuration Protocols,” IETF Network Working Group Request for Comments 2131, March 1997). Under DHCP, since the association of a hostname to an IP address is no longer static, the hostname-to-IP address list inside the DNS needs be updated whenever an IP address is dynamically assigned to a computer host, an approach known as Dynamic DNS (P. Vixie et al., “Dynamic Updates in the Domain Name System (DNS UPDATE),” IETF Network Working Group Request for Comments 2136, April 1997). In addition to dynamic IP addresses, today's Internet features mobile hosts that connect to the network via the wireless LAN. As a mobile host moves between different IP LAN segments, a new IP address needs be assigned to the mobile host, and this new association needs be reflected in the DNS entry. Thus the frequency of DNS updates has increased by orders of magnitude. Dynamic updates in DNS is designed for the very specific task of mapping a static host name to a dynamic IP address: Whenever a host acquires a dynamic IP address, the host name and the IP address are sent to a domain name server (DNS server) and if necessary this “advertisement” is propagated to other DNS servers. If other hosts on the network ask its DNS for the IP address for this host name, the DNS server returns the right IP address.
In a distributed database system, queries and subqueries are sent from the database manager that received the client's query to other database managers that have the data. However, the network topology in a distributed database system tends to be static, and all the tables are set up by the database administrator beforehand.
The Intentional Naming System (William Adjie-Winoto et al., “The Design and Implementation of an Intentional Naming System,” Proceedings of the 17th ACM Symposium on Operating Systems Principles, Dec. 12–15, 1999, Kiawah Island Resort, South Carolina, Operating Systems Review 33, No. 5 (December 1999), 186–201) also uses service directories for service discovery, and also uses periodic resending of announcements with expiration times. However, there is no distinction among service categories. All announcements are sent to all service directories. Compared with our invention, this results in more network traffic for the distribution of announcements, and requires larger memory areas since each service directory must cache all unexpired announcements.
The DataSpace project (Tomasz Imielinski and Samir Goel, “DataSpace: Querying and Monitoring Deeply Networked Collections in Physical Space,” IEEE Personal Communications 7, No. 5 (October 2000), 4–9) uses network-level multicast to distribute queries to service providers. No intermediate service directory is used to mediate the query and the service providers. A multicast group corresponds to a network index, which consists of the physical location of the service provider, and the value of one attribute distinguishing services. However, services having identical values for the network index may belong to different service categories, distinguished by a query involving other attributes. A query is distributed to all members of a multicast group, each of which then evaluates the query to determine whether its service falls within the service category specified in the query. If the service does fall within the specified category, the service provider “reflects” a response back to the requester. This imposes a significant processing overhead on providers of services in un-requested categories, and also entails more network traffic than is needed using our invention. Rapidly changing properties of provided services require the provider to leave and join multicast groups often, which can impose a heavy processing overhead. The query process can be expedited using brokers that cache information about multicast groups in a given physical region, but these brokers must be informed of every change in the membership of a multicast group, thus increasing the overhead involved in leaving and joining multicast groups.
A service directory receives a service query from a client and responds with service records corresponding to services that satisfy the query. Today's typical service directories are optimized to handle high volumes of service queries and low numbers of updates to the service records. However, this usage pattern may change in the near future, so that dynamic service records that change rapidly will increasingly constitute a larger portion of the directory entries in a service directory. One reason for this change is the emergence of a new breed of service providers, who compete with other service providers base on real-time dynamic performance related criteria (e.g., currently available response time of an advertised web service), and these metrics will be continuously updated in their corresponding service records. Another reason for this change is the increase in the number of mobile data sources that appear as service providers in the service directory. An example of mobile data source is a vehicle that outputs its location and velocity information. These new types of service providers require a service directory that can handle continuous and rapid updates to the service records.